% === Part three ===
\newpage
\chapter{Validation du projet}

\section{La recette}

Comme décrit dans la partie \ref{recette}, la recette est le test de l'application par l'équipe de développement et par le client. Voici donc une présentation du résultat final, suivie d'une analyse de cette phase.

\subsection{Présentation du résultat}

\label{rendu}

La figure \ref{layout} présente l'agencement global de la page générée par eZPublish et symfony. La partie eZ correspond principalement aux bannières et à la colonne de droite (où on voit \og Les plus Eovi \fg ) tandis que symfony commence au niveau de la zone \og \textit{1 - Votre profil > 2 - Vos besoins > 3 - Vos tarifs} \fg{} et concerne tout le cadre du milieu.

\begin{figure}[h!]
\centering
\includegraphics[width=14cm]{images/layout.png}
\caption{Présentation globale de la partie tarificateur.}
\label{layout}
\end{figure} 

\subsubsection{Les formulaires}

Pour générer ces pages (fig. \ref{form11}, \ref{form21} et \ref{form4}) , un template générique Symfony a été créé. La structure de \textit{sfForm} permettant d'itérer sur les champs comme on itérerait avec un tableau, ces templates sont relativement simples puisque qu'ils ne font qu'afficher les champs un par un (avec un certain nombre de petites subtilités pour rendre l'affichage plus joli).

L'intégration de reCaptcha en ajax est prévue dans l'API PHP de l'outil de Google. Il est ajouté ensuite dans les champs gérés par sfForm qui s'occupe de le valider via la classe qu'on lui a développée.

\begin{figure}[!h]
\centering
\includegraphics[width=12cm]{images/p1-1.png}
\caption{Page 1 : profil}
\label{form11}
\end{figure} 

\begin{figure}[!h]
\centering
\includegraphics[width=10cm]{images/p2-1.png}
\caption{Page 2 : besoins}
\label{form21}
\end{figure} 

\begin{figure}[!h]
\centering
\includegraphics[width=10cm]{images/p4.png}
\caption{Page 4 : informations complémentaires}
\label{form4}
\end{figure} 

Comme prévu dans les spécifications, le choix des dates se fait par un calendrier créé par jQuery UI\footnote{jQuery est un framework javascript très utile, et sa version UI lui ajoute de nombreux éléments d'interaction avec l'utilisateur très efficaces.}, et chaque champ est validé en javascript et côté serveur (fig. \ref{form12}).


\begin{figure}[!h]
\centering
\includegraphics[width=7cm]{images/p1-2.png}
\caption{Erreurs et Datepicker}
\label{form12}
\end{figure} 

\subsubsection{La présentation des tarifs}

Les tarifs sont calculés en internes à chaque appel de la page, pour être sûr de prendre en compte toutes les données. Ils sont directement stockés en base ensuite, sous forme de devis.

Des exemples sont présentés (fig. \ref{form3}) afin d'aider l'utilisateur à faire son choix. Lors du clic sur un des bouton radio, le bouton parallèle s'aligne automatiquement, et le prix en bas est mis à jour. Un PDF récapitulatif est également généré avec une librairie externe : HTML2PDF. Elle prend simplement en entrée un fichier HTML et le transforme directement en PDF.

\begin{figure}[h!]
\centering
\includegraphics[width=10cm]{images/p3.png}
\caption{Page 3 : tarifs proposés}
\label{form3}
\end{figure} 

\subsubsection{La souscription et le paiement}

La dernière page (fig. \ref{form5}) permet enfin au souscripteur de vérifier ses données et de choisir son mode de paiement.

\begin{figure}[h!]
\centering
\includegraphics[width=10cm]{images/p5.png}
\caption{Page 5 : adhésion à la garantie}
\label{form5}
\end{figure} 

Il est ainsi redirigé sur une des pages de paiement par chèque ou carte (la figure \ref{paiement} correspond au paiement par carte, le paiement par chèque est exactement pareil sans les logos Caisse d'Epargne). 

Tout le texte de cette page est paramétrable. Elle est en fait découpée en deux parties : mode d'emploi et adresse. Dans le backoffice, Eovi peut ensuite remplir les indications dans un éditeur de texte riche\footnote{C'est ici un synonyme de texte au format HTML.}.

\begin{figure}[h!]
\centering
\includegraphics[width=10cm]{images/paiement.png}
\caption{Page de paiement}
\label{paiement}
\end{figure} 

Un souscripteur qui aura choisi de payer par carte bancaire pourra finalement utiliser le service mis en place par la Caisse d'Epargne. Il s'agit d'une petite \textit{popup}\footnote{Petite fenêtre qui s'ouvre hors du navigateur. Souvent utilisé pour insérer des pubs.} qui s'affiche au milieu (fig. \ref{spplus}), et qui redirige vers la page voulue après le paiement.

En interne SP+ envoie au site la confirmation de paiement (ou non) via une simple requête GET sur l'URL de notre choix.

\begin{figure}[h!]
\centering
\includegraphics[width=10cm]{images/spplus.png}
\caption{Popup SP+}
\label{spplus}
\end{figure} 

\subsection{Déroulement de la phase de recette}

\subsubsection{Utilisation de Redmine}

Redmine est une application web open-source de gestion de projet. Elle permet notamment (et c'est la principale raison pour laquelle on l'utilise chez Smile) de gérer la remontée de \textit{bugs} par les clients et leur correction. Ainsi, il leur suffit de créer un nouveau ticket avec un descriptif aussi précis que possible pour nous signaler un dysfonctionnement, et de notre côté nous pouvons facilement y ajouter des commentaires pour comprendre à plusieurs ce qui ne va pas.

\begin{figure}[h!]
\centering
\includegraphics[width=13cm]{images/redmine.png}
\caption{Le \textit{bugtracking} avec Redmine}
\end{figure} 

Un serveur dédié est ainsi mis en place pour tester au maximum l'application. Il s'agit de trouver les cas limites non gérés afin d'éviter tout problème une fois que l'application sera mise en ligne.

Si certains bugs sont bloquants, ou alors à certaines échéances bien définies, l'équipe de développement met à jour le projet sur ce serveur pour lancer une nouvelle campagne de test. Entre chaque livraison il est très important de tout re-tester pour éviter des régressions\footnote{Fonctionnalités déjà testées qui ne fonctionnent plus.}.

\subsubsection{Les principaux bugs remontés}

Au total, environ une cinquantaine de bugs ont étés remontés sur la partie tarificateur. Ces bugs sont pour beaucoup des détails (formulations incorrectes, affichage erroné) et la plupart peut-être corrigé très rapidement. Cependant certains ont posé plus de problèmes, et en voici les principaux : 

\begin{description}
\item[Internet Explorer, ou le non-respect des standards.] C'est bien connu dans le monde de l'intégration web : on passe presque autant de temps à développer le site lui même qu'à l'adapter à IE. Cependant lorsque la compatibilité graphique et fonctionnelle est vendue, il n'y a plus le choix. Dans le tarificateur, le principal problème était le téléchargement de documents. Tout le formulaire passe par une protection SSL\footnote{\textit{Secure Sockets Layer}, il s'agit d'un protocole de sécurisation des échanges sur internet}, mais lors du téléchargement de documents IE7, ne parvenait à ouvrir qu'une page blanche. C'est un bug bien connu du navigateur, et pour le contourner, il a fallu modifier les en-têtes HTTP pour y forcer une mise en cache du document pendant une seconde. De cette manière seulement, IE parvenait à les ouvrir.
\item[Des exports incompatibles.] Les exports générés dans le backoffice ont été à l'origine de beaucoup de tickets (ou plutôt un ticket très très long). Principalement lié à des problèmes de formatage, ils étaient remontés un par un, à chaque livraison, provoquant une grosse perte de temps. Ceci est dû à la fois à une mauvaise communication avec le client, pour l'aider éventuellement à faire ses tests plus facilement, et aussi aux spécifications des exports qui ont été fournies de façon tardive et qui sont peu claires. Elles provenaient en effet directement du client, sous un format Excel, sans explications supplémentaires.
\item[La configuration des serveurs et les calculs avancés.] Le calcul des tarifs contenant des calculs de puissance, j'ai utilisé une librairie incluse nativement dans PHP : \textit{bcmath}. Elle permet tous les calculs avancés, avec une grande précision. Cependant elle utilise la configuration de PHP pour définir la précision des calculs par défaut, et celle-ci est ---~par défaut~--- réglée à zéro chiffre après la virgule. N'ayant pas pu enregistrer ce réglage dans un document d'installation (le chef de projet étant en vacances), cela n'a pas été fait en recette et aucun tarif n'était calculé correctement.
\end{description}

\section{Mise en ligne du projet}

\subsection{Préproduction et production}

Eovi a choisi la solution de Smile pour l'hébergement de son site internet. Un chef de projet dédié de la section \textit{Smile hosting} a donc accompagné la mise en ligne du site.

Il a d'abord fallu créer un environnement de pré-production, sensé \^etre identique à la production afin de tester si tout fonctionnait comme prévu.

Une fois les dernières vérifications effectuées, la version de production fût créée, et les DNS\footnote{Passerelle qui lie un serveur à internet} furent mis en place au matin du lundi 5 septembre. Le site est maintenant disponible à l'adresse \url{http://www.eovi.fr/}.

\subsection{Capitalisation des compétences acquises}

Ce projet n'est en fait que le premier lot d'un projet plus gros, qui comporte une deuxième partie. Le lot 2 possède en fait une structure grandement similaire au lot 1 : architecture eZ/Symfony,  création de devis...

De cette façon, beaucoup de code est et sera repris du premier lot, en optimisant son fonctionnement et en le rendant plus générique, puisque cette fois il faudra réaliser 3 tarificateurs, qui sont en soi beaucoup plus simples.